Subject: DLSw Architecture Model

From: [email-masked] (PNGacek)
Date: Tue, 05 Oct 93 07:57:56 MDT

Jim

I like the proposed architectural view of a Data Link Switch. Two small 
points on the terminology that I believe will help simplify the task of 
understanding the model.

1. The core DLSw component in your graphical representation (the octagon) 
should be labelled as "Data Link Control Manager". Describing it as a 
switch is not doing it justice. In my mind this component consists of 
functions such as Path Control, a Control Point (Management Services and 
Configuration Services) and a Network Operator Interface. Viewing it as 
purely a switch is limiting because it functionality gets quite involved 
when dealing with certain DLC types, for example, SDLC secondary devices 
(i.e. it is more pro active than reactive (the LLC end to end case)).

	         __________________
		/\                /\
	       /  \     SSP      /  \
	      /    \    over    /    \
	     /      \  TCP/IP  /      \
	    / SSP    \___vp___/ RFC1490\
	   /  over   /        \   over  \
	  /__ HPR   p          v   FR  __\
	 |   \__   v            p   __/   |
	 |      \ /              \ /      |
	 |       |      DLC       | QLLC  |
	 | etc.  v    Manager     v over  |
	 |       p (CS,MS,PC,NOF) p X.25  |
	 |       |                |       |
	 |    __/ \              / \__    |
	 |___/     v            p     \___|
	  \   HPR   p          v SDLC    /
	   \  over   \___vp___/  over   /
	    \  ATM   /        \  V.24  /
	     \      / IEEE802.2\      /
	      \    /    over    \    /
	       \  /   IEEE802.x  \  /
	        \__________________/

2. Given the above I believe that the DLSw SSP style terminology should 
be contained to the DLSw DLC and therefore the virtual port should not 
have CANUREACH as the function name. Something like FIND ROUTE or FIND 
STATION seems better.

Regards Paul Gacek

---

From: "Jim (J.) Cobban" <[email-masked]>
Date: Tue, 5 Oct 1993 13:29:00 +0000

>(i.e. it is more pro active than reactive (the LLC end to end case)).

I am not certain that I understand the last part of this point.  The primary
point which I am trying to make is eliminating any DLC specific
functionality from the core of the switch.  Handling the peculiarities of
SDLC secondary, to use your example, would be entirely the responsibility of
the DLC instance.  For example the SDLC secondary DLC implementation still
receives a DL_CONNECT message, but instead of sending a SNRM, as the SDLC
primary implementation would do, this conditions the interface to respond to
SNRM with UA.

My only reservation about calling it a DLC "Manager" is that it implies that
it isn't on the data path.  For example in the APPN architecture there are
two entities, the Session Connector (ISR.SC) and the Session Connector
Manager (ISR.SCM).  Only the Session Connector is on the data path, the
manager gets involved only to handle BIND and UNBIND.

In addition in my model every entity is responsible for its own
configuration and management.  That is because otherwise the core component
would need to understand the implementation specific requirements of
specific DLCs.  Putting that sort of functionality in the core would mean
that adding a new DLC type would require changes to the core.

The DLSw core, as I envision it, includes topology management for the MAC
and NetBIOS resource name tables, connection setup, and data path.  It does
not include the network operator interface or configuration services or
management services.  Those are independent functions which interface to
every component of the switch.

Some clarity in terminology is desireable since users will tend to view the
complete functionality as the DLSw.  A label like DLSw Core, to represent
the data link control independent portion of the function would be
reasonable, particularly since the graphic I drew looks like an apple cut
into segments.

---

From: "Shannon Nix" <[email-masked]>
Date: Tue, 5 Oct 93 17:12:38 EST

Jim,

I like your architectural model proposal very much.  It matches very closely
the model that we have been designing towards. Specifically: 

  1. The actual switching fabric is independent of the DLC type.
  2. SSP is simply another DLC type.

Some of the implications of this are:

  1. Many of the issues we are discussing in the siglets are SSP data link 
     issues:

  2. The DLSw "core function" should be described as a set of FSMs and inter
     process signals with respect to two generic DLC instances rather than
     a DLC instance and an SSP instance.

  3. I agree with Jim that the core functions should include:

     1.  Connection setup
     2.  Data Routing
     3.  Route/Name Caching/Discovery

Rgds, Shannon

>that adding a new DLC type would require changes to the core.
  I agree with this point also.

>every component of the switch.

  Ditto!
>reasonable, particularly since the graphic I drew looks like an apple cut
(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)(*)   Shannon Nix    (*)(*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)      Netlink, Inc.     (*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)  3214 Spring Forest Rd.   (*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)  Raleigh N.C. 27604 USA   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)  Phone:  (919)-878-8612   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)  Fax:    (919)-872-2132   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*) Internet: [email-masked] (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)

---

From: [email-masked] (PNGacek)
Date: Thu, 07 Oct 93 16:44:30 MDT

Jim

To reiterate my earlier point I like your proposal with the following 
comments. 

The core component is a data switch, a connection manager and a  route 
manager ( lets exclude the management type stuff for the time being).  I 
believe that using the term DLSw or any related term is a bit misleading 
given that we (including Shannon) agree that DLSw should be viewed as a 
DLC and that the core component should be as devoid as possible of DLC 
specific details. Using DLSw as the name for the core component conjures 
up visions of SSP and RFC 1494 functions.  I agree that SLDC items such 
as SNRMing etc belong in the SLDC DLC as do CURing events belong in a  
DLSw DLC (hence my comment about removing that from your virtual port 
service definition). 

The point about pro active and re active relate to the belief that when 
the core component is working with a primary SDLC DLC,  it's role is more 
involved than when dealing with a DLC such as LLC. For example, 
establishing a connection to an SDLC based CU from a router, the core 
component (under some circumstances) needs to consciously make the 
descision (i.e. is pro-active) to establish the connection. This differs 
when dealing with LLC connected devices where the stimulus to connect is 
external (i.e. the core component is reactive) coming from either the CU 
or host.

Where the management components reside is personal taste and could either 
be part of a DLC Manager or some component to the side.

My points are mainly semantic in nature (with the exclusion of the 
management stuff which is entirely subjective).

Regards Paul Gacek
Novell

---

From: "Jim (J.) Cobban" <[email-masked]>
Date: Fri, 8 Oct 1993 09:46:00 +0000

In message "Re: DLSw Architecture Model", 

>DLSw DLC (hence my comment about removing that from your virtual port 
I do not interpret Shannon's comments as indicating agreement that DLSw is
viewed as a DLC.  The SSP is a DLC, the switch is a switch.  The primary
purpose of the component which I call DLSw core is switching, the
establishment of connections through the DLSw core is incidental.  

>external (i.e. the core component is reactive) coming from either the CU 
No I cannot agree with you. My view is to totally exclude DLC specific
functionality from the core switch.  That is why it is necessary to include
the CUR functionality in the virtual port interface.

You are focussing on a very narrow point, that a secondary PU 1 or 2 cannot
send a frame to indicate that it wishes to establish a connection.  However
a secondary SDLC device does not exist in a vacuum.  It is always associated
with a primary SDLC device, that is with a host.  There is clearly no
necessity that every device attached to the data switch be capable of
initiating connections.  For example there are many TRN networks in which
the host (NCP) does not initiate connections but rather waits for the
terminals to connect inward.  That is for several reasons:

  1) it is administratively more complex to define the MAC/SAP pairs for all
     terminal devices centrally.  Each entry in the central table is unique,
     where the host MAC/SAP configured in a remote PU is generally always
     the same and can be cloned from controller to controller.
  2) If connections are initiated from the terminal end then it is easy to
     configure backup TICs and allow source-route bridging to select the
     active TIC, or to load balance the TICs.

How is the situation where a host never initiates connections through the
switch any different from a situation in which a terminal never initiates
connections through the switch, merely passively waiting for a connection to
be delivered to it?  

In any event the SDLC DLC instance which is connected to an SDLC controller
can be configured to initiate the DLC connection automatically, and to
initiate a DLSw connection based upon response to XID or SNRM.  Or it could be
configured to initiate the DLC connection only upon receipt of a CUR,
although that risks misleading 

>be part of a DLC Manager or some component to the side.
I do not feel that this is an item of personal taste.  Only if the DLSw core
is the only manageable component of the switch does it make sense to
incorporate the management interface into the core.  In my proposed model
each of the DLC instances is individually manageable, and it therefore makes
sense to use a shared management interface which provides access to all
manageable components.

I refer you to the IEEE 802 model, in which management is a separate layer
which accesses each of the layers of the LAN entity.  This is particularly
relevant since the whole DLSw looks like a bridge to the LAN.

>management stuff which is entirely subjective).

On the contrary I believe that your points represent a fundamental
misunderstanding of the thrust of my argument.  In essence you are agreeing
with me about trivial detail while disagreeing with the basic philosophy of
the model.

---

From: [email-masked] (PNGacek)
Date: Fri, 08 Oct 93 09:27:45 MDT

Jim

Isn't email fun!

Let me reread your original model before we continue with a seemingly 
derailed discussion.

Regards Paul Gacek
Novell